The BIND 9.x server implementation must uniquely identify and authenticate the other DNS server before responding to a server-to-server transaction, zone transfer and/or dynamic update request using cryptographically based bidirectional authentication to protect the integrity of the information in transit.

Overview

Finding ID	Version	Rule ID	IA Controls	Severity
V-72429	BIND-9X-001100	SV-87053r1_rule		High

Description
Server-to-server (zone transfer) transactions are provided by TSIG, which enforces mutual server authentication using a key that is unique to each server pair (TSIG), thus uniquely identifying the other server. DNS does perform server authentication when TSIG is used, but this authentication is transactional in nature (each transaction has its own authentication performed). Enforcing mutually authenticated communication sessions during zone transfers provides the assurance that only authorized servers are requesting and receiving DNS zone data. Without authenticating devices, unidentified or unknown devices may be introduced, thereby facilitating malicious activity. Failure to properly implement transactional security may have significant effects on the overall security of the DNS infrastructure. The lack of mutual authentication between name servers during a DNS transaction would allow a threat actor to launch a Man-In-The-Middle attack against the DNS infrastructure. This attack could lead to unauthorized DNS zone data being introduced, resulting in network traffic being redirected to a rogue site. Satisfies: SRG-APP-000158-DNS-000015, SRG-APP-000390-DNS-000048, SRG-APP-000394-DNS-000049, SRG-APP-000395-DNS-000050, SRG-APP-000439-DNS-000063, SRG-APP-000440-DNS-000065

Description

Server-to-server (zone transfer) transactions are provided by TSIG, which enforces mutual server authentication using a key that is unique to each server pair (TSIG), thus uniquely identifying the other server. DNS does perform server authentication when TSIG is used, but this authentication is transactional in nature (each transaction has its own authentication performed). Enforcing mutually authenticated communication sessions during zone transfers provides the assurance that only authorized servers are requesting and receiving DNS zone data. Without authenticating devices, unidentified or unknown devices may be introduced, thereby facilitating malicious activity. Failure to properly implement transactional security may have significant effects on the overall security of the DNS infrastructure. The lack of mutual authentication between name servers during a DNS transaction would allow a threat actor to launch a Man-In-The-Middle attack against the DNS infrastructure. This attack could lead to unauthorized DNS zone data being introduced, resulting in network traffic being redirected to a rogue site. Satisfies: SRG-APP-000158-DNS-000015, SRG-APP-000390-DNS-000048, SRG-APP-000394-DNS-000049, SRG-APP-000395-DNS-000050, SRG-APP-000439-DNS-000063, SRG-APP-000440-DNS-000065

STIG	Date
BIND 9.x Security Technical Implementation Guide	2018-04-03

Details

Check Text ( C-72629r1_chk )
If zone transfers are disabled with the "allow-transfer { none; };" directive, this is Not Applicable. Verify that the BIND 9.x server is configured to uniquely identify a name server before responding to a zone transfer. Inspect the "named.conf" file for the presence of TSIG key statements: On the master name server, this is an example of a configured key statement: key tsig_example. { algorithm hmac-SHA1; include "tsig-example.key"; }; zone "disa.mil" { type master; file "db.disa.mil"; allow-transfer { key tsig_example.; }; }; On the slave name server, this is an example of a configured key statement: key tsig_example. { algorithm hmac-SHA1; include "tsig-example.key"; }; server { keys { tsig_example }; }; zone "disa.mil" { type slave; masters { ; }; file "db.disa.mil"; }; If a master name server does not have a key defined in the “allow-transfer” block, this is a finding. If a secondary name server does not have a server statement that contains a "keys" sub statement, this is a finding.

Check Text ( C-72629r1_chk )

If zone transfers are disabled with the "allow-transfer { none; };" directive, this is Not Applicable.

Verify that the BIND 9.x server is configured to uniquely identify a name server before responding to a zone transfer.

Inspect the "named.conf" file for the presence of TSIG key statements:

On the master name server, this is an example of a configured key statement:

key tsig_example. {
algorithm hmac-SHA1;
include "tsig-example.key";
};

zone "disa.mil" {
type master;
file "db.disa.mil";
allow-transfer { key tsig_example.; };
};

On the slave name server, this is an example of a configured key statement:

key tsig_example. {
algorithm hmac-SHA1;
include "tsig-example.key";
};

server {
keys { tsig_example };
};

zone "disa.mil" {
type slave;
masters { ; };
file "db.disa.mil";
};

If a master name server does not have a key defined in the “allow-transfer” block, this is a finding.

If a secondary name server does not have a server statement that contains a "keys" sub statement, this is a finding.

Fix Text (F-78781r1_fix)
Configure the BIND 9.x server to use TSIG keys. Add a key statement to the "named.conf" file for TSIG that is being used: key tsig_example. { algorithm hmac-SHA1; include "tsig-example.key"; }; Add key statements to the allow-transfer statements on a master name server: allow-transfer { key tsig_example.; }; Add key statements to the server statements on a secondary name server: server { keys { tsig_example }; }; Restart the BIND 9.x process.

Fix Text (F-78781r1_fix)

Configure the BIND 9.x server to use TSIG keys.

Add a key statement to the "named.conf" file for TSIG that is being used:

key tsig_example. {
algorithm hmac-SHA1;
include "tsig-example.key";
};

Add key statements to the allow-transfer statements on a master name server:

allow-transfer { key tsig_example.; };

Add key statements to the server statements on a secondary name server:

server {
keys { tsig_example };
};

Restart the BIND 9.x process.